I think, we want to continue this in macros. Just not, if the is_some/... and the unwrap/... are arguments of the macro.

So

macro_rules! m {
    ($a:expr) => {
         if $a.is_some() {
              $a.unwrap();
         }
    }
}

m!(Some(42))

should still get linted.

That being said: I have no idea how differentiate these case. Maybe somehow with

Oh, indeed! Re-covered it in 19ce66c, how about?

Oh yeah, just allowing it in external macros works. At least for assert. The FP still exists when an internal macro is used though:

macro_rules! m {
    ($a:expr, $b:expr) => {
         if $a {
              $b;
         }
    }
}

let x: Option<u32> = Some(42);
m!(x.is_some(), x.unwrap())

(At least, I think so)

Ugh, it seems so. But I feel it's another FP and unrelated to the issue directly. If you think this PR is an improvement and doesn't have any other regressions, I'd say move on as it is and file that FP as a new issue.

Yeah, lets merge this, since it fixes the most prevalent issue with assert!. Thanks!

@bors r+

📌 Commit 19ce66c has been approved by flip1995

⌛ Testing commit 19ce66c with merge 0c6d55b...

💔 Test failed - checks-travis

Seems spurious:

thread 'integration_test' panicked at 'clone of repo failed: Error { code: -1, klass: 2, message: "failed to connect to github.com: Connection timed out" }', tests/integration.rs:22:5

@bors retry

⌛ Testing commit 19ce66c with merge a3135ba...

☀️ Test successful - checks-travis, status-appveyor
Approved by: flip1995
Pushing a3135ba to master...